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President f s Message 
by Bruce Campbell 


Well this is the beginning of a new club year, and we are in need of articles for the newsletter, as well 
as more membership participation* This is YOUR club and will only be as good as you wish to make it. 

We are planning on setting up a demonstration at one of the large shopping centers but this will not be 
until November* Anyone interested in helping can contact one of the executive* 

Once again, it's time to renew your registration dues for the coining year. The yearly dues have stayed the 
same as last year ($20.00)- 

The club is now a registered non-profit organization thanks to the efforts of A1 and Carole Anderson. 

k k k k k 

The newly elected executive consist of: 

President - Bruce Campbell 837-9060 
Vice-President - Stu Marcel lus 668-2178 
Secretary - Ray Finch 661-6670 
Treasurer - Carole Anderson 632-1206 
Mews letter Editor - Rick Singbeil 889-0098 
Member at Large - Warren Champagne 253-0186 
Member at Large - Dave Zimmerman 661-4165 
Member at Large * A1 Anderson 632-1206 

* * * * * 


From the Editor 
by Rick Singbeil 

Due to the lack of interest in taking over the newsletter I have volunteered my services for one more year. 
,iis year as Editor, my job will consist of editing the articles submitted. Hopefully it will be an interesting 
year reading all the articles submitted. 

As a regular feature, we will place a few articles from Genie BBS in the newsletter- The whole article will 

be available on our BBS or through any of the libraries if there is interest, 

A few members have asked for more clarification on the 800XL upgrade (a diagram) and this will be placed in 

next months newsletter if the diagram can be found. If not, maybe Warren or Fritz could be of help as they both 

built the modification. 

One last thing,.,** the battery backup system is finished and could be placed In the newsletter although 
due to the cost of it ($175.00) 1 don't know if anyone would like to build it- If your interested I'd like to 
hear from you* 

k k k k k 


A LOOK AT THE FUTURE? 
reprinted from ABES ACES 

It 1 s impposible to know just what the future holds but one thing is certain... there WILL be changes. We' ve 
come to expect the changes, as they relate to our computer "enthusiasm" , to mean more power/speed for less 
money -The reason? Overall, the technological advances in chip production have lowered memory costs tremendously. 
This technology is now being applied to new forms of information storage. 

MEMORY CASSETTES 

A case in point; Dupont Conductor systems recently introduced a line of memory cassettes. They come in ram 
and rom versions from 32K to 1 Meg, The largest cassette is about the size of a credit card* It holds 1 Meg of 
static ram and, at this time, sells for about $200.00. This price will no doubt drop as production Increases. 

According to Dupont's news release on the product/'memory cassettes can be used anywhere the convenience of 
an interchangeable module is needed. As an erasable recording medium, the ram cassettes serve as a compact 
external memory, and can replace a floppy disk and drive-" 

Think about it- Available today, a credit card sized cassette on which you can store and retrieve one 
gabyte of information* Ca a 2,5 or 10 meg card be far away?? 

What are the advantages? The card will not be easily damaged as a disk drive or especially a hard drive 
„ould be during transportation. In fact with no moving parts, you should never have to worry about any kinds of 
repairs. Easy to transport, it would fit in a shirt pocket or could be mailed easily, Even the the pin and socket 
assembly has been designed for a minimum of 10,000 mating cycles, And if speed is what you want nothing could 
touch it in that regard. 
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So while you can't plug one into your ATARI at the moment, don 1 t be suprised if at some future CES it's 
announced that this technology has been incorporated into a new model. 

Thanks to Dr.Subash Khadpe editor and publisher of Semiconductor Packaging update (Neffs ,FA) for making 
this information available to me for this article. 

Warren Champagne 
* * * 


REPRINTED FROM THE S.L.C.C. JOURNAL 

Zzzzzzz t . ******** zzzzzzzzzzzttttt zzzzzttt zzzzzt. 

What the heck are those kids doing on Roberts computer? 

Zzzzzzzzztttttttt* zzzzztttt, ■ * zzzzzzzzzzzzzzzt . .. .zzzzzztttt! I 

Taking pity on the poor 1050,1 venture down from the attic with visions of all those little plastic pieces 
self-destructing inside the drive. 

These machines only have so many seeks in them, then its move into room 144 for the duration. 

Hmimrnmnro. Leather Goddess of Phobos! Seems like someone actually read a review in the Journal I I suppose 
that this sudden INTEREST comes with the fuzz on the upper lip and the feet that are to big. Mrs. Pacman is 
relegated to the cartridge case - Strip poker and LGOP are the hot items now! I The boys will survive this phase 
I suppose, but judging from all the seeks that poor old 1050 has to do it may never see the other side of 14. 
Every time mark enters a command the program goes to the drive!! I either have to ruin their fun or find a 
better way 

The answer is to run from ramdisk,of course. Since I have a very trick piece from ICD,it should be easy. Take 
out the old MIO and plug it into Robert’s 800x1.1 know from experience that the 256k upgrade in his computer 
will not run most games since you have to have a handler in there someplace. With the M0 and it'S built in PIO 
handler, it should be a piece of cake. Sector copy side 2 the side the game is run from onto the MI0 ramdisk, boot 
from side 1 in the 1050 and swap Dl: and D2: with a select/ reset 

Guess what??? It doesn't work 256k In the 800XL,256k in the MIQ and I still have to run to the 1050 for 
every entry!!! What a drag!! It seems that the program will not take being RESET. You have to switch disks when 
it asks you without disturbing any part of the memory. @£" $&{§&(&#! ! If I just had some way to vector the I/O 
externally 

~ with a switch or something. (oh, boy! He's gonna take the thing apart and hack in a bunch of wires and 
stuff ) 

Maybe I can adapt the PIO controller that I'm working on in the attic?.*. Take a Supra Microport, add a 
couple of ic's a switch or two, and write a little handler.... VoilaUA programmable, switch - selectable, PIO 
controller! i 

Take 4 IC's and a supra microport XL. It uses the memory under the ROM at location $D800-$D8ff. You load 
any PIO code you like in there and run your program. It could be used as a printer buffer, screen dump 
routine, 1/0 indirection, ramdisk, or any thing that uses interrupts, reset or SIO, The OS traps all three 
operations through the PIO code. I used the reset vector to provide a FREEZER (cold-start) function and the SIO 
vector to run 2 96K ramdisks.Two switches select which ramdisk if any, will respond to Dl: 

Downstairs to the Den of Phobos... sector copy side 1 to RD1 and side 2 to RD2.Set Dl: as EDI and cold 
start using the new PIO function. Up comes the screen asking for side 2..,., set RD2 as Dl; and hit return,.., and 
off they go into the cosmic clashes - no disk access at all!!! As an added bonus, the 1050 is set to D2: 
whenever a ramdisk is selected as Dl:,so it is used for save and restore. Works great!! I can finally use all 
this memory on programs not designed for ramdisks! 

Now that I have your undivided attention this is the next hardware mod on my agenda, if it works and I can 
get the parts the instructions and diagrams will be included In a future newsletter. I also have the source code 
for the handler if anyone Is interested in that aspect of it, This mod is for the SGQXL's parallel bus but if you 
get the special connector to convert the 130's parallel bus structure to conform to the xl's structure 1 see no 
reason it should’ nt work on it as we 11, well a little more from the article and you can go on to more important 
things. 

Plug the microport into the connector on the back of your XL and load the PIO code. When you hit RESET, the 
controller will be enabled on the PIO buss, Hold the COLDSTART switch down when you RESET, count to 3 after you 
release the RESET key and let go of the COLDSTART. The system should go to the diagnostic (??-- thats a 
diagnostic???) screen. From there, you will COLDSTART when you hit RESET, or hold OPTION at this point to disable 
basic. 

The operation of the two switches is progammed to enable 96K of RAMBG memory as a ramdisk that responds to 
SIO requests to Dl;.When either ramdisk bank is enabled, the drive numbers are bumped by 1- that is, a drive 
addressed as Dl: on the SIO buss will answer a SIO call to D2: YOU can program it any way you want - you don't 
need an eprom burner for this baby! In fact there is no memory in the hardware at all. 

If you would like it to be able to select more options on your unit, add switches to pins 12 thru 16 of 
ICS, The COLDSTART switch will LDA from $Dlxx as an $80.RDx reads as $01. I leave the other values as an exercise 
to the programmer. 

For those of you with an XL without the 256K upgrade — there is a version of this project that has up to 
256K of battery retained memory up in the attic. . .somewhere probably near the 1200XL version* ** .someplace. .* . 

Well thats it for now I'll keep you all up to date on this and let you know how I make out and what the 
cost will be. 


Warren Champagne 
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* * * * * 


THE FOLLOWING THREE ARTICLES (ISSUE #66, #65 6 #64) COME FROM GENIE BBS. THEY ARE ON OUR BBS IN FULL FOR 
ANY MEMBER TO DOWNLOAD AND READ. LOOK FOR THESE ARTICLES IN THE ARCED SECTION OF OUR BOARD. 

Taken from Zmag66 


Xx ZMAG INTERVIEW 


This is an interview with Chuck Leaaott of the Hard Disk Users Group and the NETWORK; Atari BBS in San 
Antonio Texas. The interview was conducted on August 13, 1987. 

RON: Good day Sir, Please tell our readers about the HDUG, and why you started this User Group? 

MRZ: OK, (DEEP BREATH). HDUG (HARD DISK USER GROUP) IS DESIGNED AROUND SYSOPS THAT HAVE THE YEARNING TO 

OPERATE A HARD DRIVE WITH THE ATARI COMPUTERS. 

IT'S REALLY FOR EVERYONE WISHING TO RUN A HD, BUT ARE AFRAID TO START DUE TO A LACK OF KNOWLEDGE. 

WE STARTED THE GROUP AS A RESULT OF A CONVERSATION WITH TOM HARKER AT ICD. SINCE THEY ARE NOW SUPPORTING 

HD'S, WE NEEDED A PLACE TO COORDINATE ALL THE HD ACTIVITY. THUS, HDUG HAS BORN. I HAVE TO GIVE CREDIT WHERE 
CREDIT IS DUE, AND IT WAS REALLY TOM'S IDEA. SINCE HE DIDN'T REALLY HAVE THE TIME, I TOOK IT UPON MYSELF TO 
GOPHER IT. 

RON: Were you running a BBS system before HDUG existed? 

MRZ: YES, I HAD A SIMPLE SYSTEM (STARTED WITH AMIS, OF ALL THINGS). 

AFTER TALKING TO TOM, I BOUGHT A HD. 

I'VE BEEN INTO BBS'N SINCE 1982, AND STARTED WITH A SINGLE 1050 (AND "NO" RAMDISK) . USING ATARI DOS 3.0 
DIDN'T REALLY TICKLE ME. 

RON: I know what you mean!!! What would a perspective HD user get out of joining this user group? 

MRZ: WELL, IT DEPENDS ON A LOT OF THINGS. THE NEWSLETTER IDEA IS A DEVICE SET UP TO SPREAD NEWS ON HD 

SYSTEMS, AND THE HOW'S, WHERE'S, AND EVEN WHY'S OF USING A HARD DRIVE RATHER THAN A FLOPPY/ RAMDISK COMBINATION. 

YOU HAVE TO REALIZE THAT IN THE FIRST PLACE, YOU HAVE TO HAVE $$$ TO GET THE HD, BUT IT DOESN'T HURT FOR 
TOO LONG. 

RON: Sounds interesting. How about some membership instructions. 

MRZ: SURE... WE CHOSE A VERY LOW COST FOR MEMBERSHIP. IT TAKES QUITE A BIT OF TIME TO GET THE DATA 

TOGETHER FOR THE NEWSLETTER (YOU KNOW ALL ABOUT THAT PART) , AND PRINTING COSTS ARE NO PICNIC. SO, $18 FOR A 1 
JAR SUBSCRIPTION TO THE NL SOUNDED REASONABLE. THE NL IS CURRENTLY A QUARTERLY, AND SEEMS TO BE GETTING OFF ON 
HE RIGHT TRACK. 

FOLKS CAN JOIN HDUG BY WRITING TO: 

NETWORK: HDUG 
5831 SUN BAY 
SAN ANTONIO, TX 
78244 

WE ASK THAT YOU PLEASE INCLUDE ANY DATA THAT YOU WISH TO HAVE INSERTED IN THE NL. THINGS LIKE LOCAL BBS'S 
AND USER GROUPS. ALSO, IF YOU HAVE A HARD DRIVE SETUP, WE WOULD REALLY LIKE TO KNOW WHAT COMPONENTS IT CONSISTS 
OF. 

RON: Talking about components. Do you include both 8 and 16-bit in your group? 

MRZ: YES. IF YOU SUPPORT ATARI, WE SUPPORT YOU. ANYTHING AND EVERYTHING THAT ATARI EQUIPMENT CAN HANDLE 

IN THE HARD DISK INDUSTRY WE WANT TO KNOW ABOUT. ALL INPUTS COME FROM THE MEMBERS OF THE GROUP. IF YOU DON'T 
TELL US, WE DON'T KNOW YET. 

RON: What other offers are available to members? 

MRZ: OH, THERE ARE MANY DISCOUNTS ON PRODUCTS FROM LOTS OF FOLKS. ONCE WE ESTABLISH "RELATIONSHIPS" WITH 

COMPANIES, WE USUALLY CAN GET SOME FORM OF DISCOUNT ON HARDWARE AND SOFTWARE FOR THE HD SYSTEMS. FOR EXAMPLE, 
THERE ARE 2 NEW "BACKUP" UTILITIES DESIGNED TO HELP THE HARD CORE USEES BACKUP THEIR SYSTEMS TO FLOPPY AND HD. 

FLASHBACK! AND HARDBACK (FROM ICD AND ORION MICRO SYSTEMS, RESPECTIVELY) ARE OFFERED TO MEMBERS WITH AT A 
SUBSTANTIAL DISCOUNT. ALSO, HARDWARE IS OFFERED AT A DISCOUNT. 

RON: I have read a few messages on the Zmag BBS about users looking for hard disk information and repair. 

Does your group assist with helping members or offering members repair information or a service? 

MRZ: WELL, YOU HAVE TO UNDERSTAND THAT THE HARD DISK USER GROUP IS UNIQUE IN THE RESPECT THAT IT'S TOTALLY 
A "MAIL-ORDER" USER GROUP. 

ANY CORRESPONDENCE IS ON MODEMS AND BBS'S THAT HELP SUPPORT US... LIKE YOUR SYSTEM. SO, WHEN A MEMBER HAS 

PROBLEMS OR QUESTIONS, WE CAN LEAD THEM TO THE RIGHT PLACE (AND CHEAPEST) TO GET THE PROBLEM SOLVED. 

SOME THINGS WE CAN HANDLE IN THE MESSAGE BASES BUT OTHERS, OF COURSE, HAVE TO BE REFERRED. 

RON: What would you suggest (Hard Disks) for new hard disk buyers? 

MRZ: HMMM... THAT'S TOUCHY, SINCE I DEAL WITH A LOT OF DIFFERENT PLACES AND DON'T LIKE PLAYING FAVORITES 

(EVEN THOUGH I HAVE SOME). BUT, LET'S SEE... ICD IS ONE COMPANY THAT WILL RESEARCH PROBLEMS WITH SYSTEMS THEY 
SELL, AND OTHER SYSTEMS THAT YOU HAVE. LURIE AND ASSOCIATES HANDLE THEIR NEW "BTL" HD SYSTEMS, AND OF COURSE 

^HERE'S ALWAYS SEAGATE, INC., WHICH REALLY KNOWS THE IN'S AND OUT'S OF THE "THEORY" BEHIND HD SYSTEMS. 

RON: Sounds like a lot of work for a new hard disk buyer. 

I suppose you would suggest an MIO to your future HD buyers, are there any other interfaces available to 
.uari users? 

MRZ: WELL, AGAIN... I HAVE MY FAVORITES, BUT THERE ARE NUMEROUS SYSTEMS TO USE. SUPRA HAS AN INTERFACE 

DESIGNED FOR BOTH ATARI 8/16 BIT SYSTEMS. THE BTL IS USEFUL, AND IS QUITE SIMILAR TO ICD'S MIO INTERFACE. 

SINCE I HAVE AN MIO, I HAVE TO SAY THAT IT'S PERFECT FOR MY NEEDS. 
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I'M NOT SURE WHAT THE DRIVE SPEC CAPACITY IS ON THE OTHER COMPANIES' INTERFACES, BUT USING SPARTA DOS AND 
THE MIO WILL ALLOW A PERSON TO RUN A WHOPPING 128 MEGABYTES ON A $59.95 8-BIT ATARI COMPUTER WITHOUT A BIT OF 
TROUBLE. I RUN 120 MEGS. 

RON; Before we terminate this interview, what features are available on the Network Atari BBS and what are 
the future plans for HDUG? 

MRZ: WELL, WE'RE IN THE MIDDLE OF A CONFLICT HERE AT NETWORK... WE HAVE TO MAKE EVERYONE HAPPY, WHICH IS 

OUR BUSINESS, BUT TRYING TO FIND THE BEST BBS PROGRAM TO LET US USE ALL 120 MEGS ON-LINE IS A CHORE. CURRENTLY, 
LIKE YOURSELF, WE RUN THE OASIS BBS (SORRY KEITH AND EVERYONE ELSE) . 

THIS ALLOWS US TO HAVE ALL OUR D/L'S ON-LINE AT ONCE. KEITH LEDBETTER WILL SOON BE RELEASING A NEW VERSION 
OF THE 850 EXPRESS! BBS, AND WE ARE SLATED TO DO THE BETA TESTING SHORTLY. AS A MATTER OF FACT, I'LL BE DOING 
AN INDEPTH INTERVIEW WITH KEITH THIS COMING SATURDAY ABOUT THIS NEW SYSTEM. 

WE'LL KNOW MORE AT THAT TIME. NOT TO DRAG ON, BUT I LIKE TO BE SURE THAT EVERYONE KNOWS THAT I SUPPORT 
"ANY" BBS THAT SUPPORTS ATARI. IN THE NEXT ISSUE OF THE HDUG NEWSLETTER WE'LL HAVE A COMPLETE REVIEW OF MOST OF 
THE POPULAR BBS'S, AND PIT THEM TOGETHER. YOU DECIDE WHICH SYSTEM SUITS YOU BEST. 

RON: (Last question) 

Do you have information about ICD news for the months ahead, and expectations on the user group? 

MRZ: WELL, I CAN SAY THAT AFTER SPEAKING WITH THE CREW AT ICD, THEY EXPECT TO RELEASE ALL THE NEW PRODUCTS 

IN A MAD RUSH. I'VE BEEN TOLD THAT IT WILL BE BEFORE CHRISTMAS, BUT DON'T TAKE THAT WRONG. I ASKED TOM IF THEY 

WERE WAITING FOR THE XMAS RUSH, AND HE SORTA CHUCKLED AND SAID ABSOLUTELY NOT. ONE OF THE SLATED PRODUCTS, 
SPARTA DOS 4 ELITE, HAS BEEN CANCELLED, BUT THEY WILL TAKE ALL THOSE FILES AND PROBABLY INCLUDE THEM INTO THE 
"TOOLS" DISK. 

THIS SOUNDS TERRIFIC, AND I'VE SEEN SOME OF THOSE TOOLS IN ACTION AT THE ICD OFFICE. WE CAN EXPECT TO BE 
TREATED WITH AN ARMLOAD OF THINGS THAT WE’VE ALL BEEN PATIENTLY WAITING FOR. 

AS FOR THE HARD DISK USER GROUP, I'M WORKING ON SOME "TOOLS" MYSELF, AND HAVE ENLISTED THE PROGRAMMING 

EFFORTS OF ONE OF THE "SLEEPER" PROGRAMMERS IN THE 8-BIT COMMUNITY. DON PEASLEY IS HIS NAME, AND YOU CAN ALL 

REST ASSURED THAT YOU'LL BE HEARING MANY EXCITING THINGS FROM HIM. 

RON: Ok... Please give us your Network: Atari BBS Number and address again for those who probably read on 

past it. 

MRZ: SURE.. 

NETWORK: ATARI 
5831 SUN BAY 
SAN ANTONIO, TX. 

78244 


VOICE: 512-662-9764 

MODEM: 512-662-9765 (ANY TIME/BAUD) 

NOTE: TO ALL YOUR READERS... PLEASE DON'T CALL MY VOICE NUMBER AT 3AM THINKING IT'S THE BBS. HEH. 

RON: Ok Chuck, I want to thank you for this interview. I hope we have covered a few of the important 

aspects and will be calling on you after the release of your next newsletter. 

MRZ: WELL THANX A MEG, AND I'D LIKE TO RAMBLE TO YER READERS FOR JUST A SEC. DO YOU MIND? 

RON: Not at all!!!! 

MRZ: OK, LET'S ME SAY THAT STARTING A HARD DISK SYSTEM FOR THE ATARI SYSTEMS, OR ANY SYSTEMS, CAN BE A 

TRYING THING. IT'S NOT SOMETHING THAT IS DONE EASILY, BUT ONCE YOU GET INTO IT IT'S REALLY FUN! DON'T BE 
INFLUENCED BY OTHERS THAT HAVE HAD "TROUBLE" WITH THEIR SYSTEMS. GET THE FACTS. 

DO IT SMART. GET ALL THE DETAILS "BEFORE" YOU BUY YOUR PRODUCTS. BECAUSE, ONCE YOU’VE INVESTED "MEGGA" 
BUCKS IN YOUR SYSTEM, YOU ARE STUCK WITH IT. LOOK AROUND. SHOP. SEE WHAT ALL THE RUCKUS IS ABOUT. DON'T BE 
HASTY IN THE PRODUCTS YOU PURCHASE. FIND A DEPENDABLE COMPANY THAT WILL REALLY "SUPPORT" YOUR HARD EARNED MONEY. 

LASTLY, CALL ME... I'LL FIX YOU UP WITH ALL THE INFORMATION YOU NEED TO HAVE. 

THANKS FOR THE TIME, AND A TIP OF THE HAT TO ANYONE THE BUYS ATARI!! 

RON: Chuck, Thanks again. Good luck with the group. 

MRZ: THANK YOU RON, HOPE ALL THE HDUG EFFORTS DON'T CRASH!! CHOW. 

***** 


Taken from Zmag65 


Xx ATARI NEWS UPDATE 


From CompuServe Online Today 

Atari Corp. profits are up 39.3 percent and sales are up 16.4 percent in the second quarter. 

According to The Associated Press, this puts the Sunnyvale, Calif., computer maker's net income for the 
quarter at $13,5 million, or 23 cents a share, compared to $9*7 million, or 22 cents a share on fewer 
outstanding shares, a year earlier. 

The wire service says sales for the quarter were $70.7 million compared to $60.7 million for the same 
quarter last year. 

Looking, then, at the first six months of this year, net income for Atari was $28.8 million compared to 
$12.4 million, an increase of 132 percent. Sales for the first half were $135.8 million compared to $105.6 
million for the same period last year, an increase of 28.6 percent. — Charles Bowen 

Atari's new Mega ST computer has been released for sale in Germany and Switzerland, The 2 Mb version of 
the Mega ST is selling for 3,000 Swiss Francs — about $2,000 OS — and the 4 Mb model is an additional 400 


Page 5 


Swiss Francs ($270) , This confirmed comments made last month by an Atari executive that release of the new 
nodel was imminent. 

The Swiss model was released without a "blitter", a newly developed coprocessor chip that acts as a 
nigh-speed memory manager. Among other tasks, the blitter is expected to control animation and screen graphics* 
Some US observers were disappointed that the first machines were manufactured without the coprocessor but Neil 
Harris, Atari's director of marketing communications, said that he expects US machines to include the blitter. 
Commenting on why the Mega ST showed up In Switzerland before the US, Harris told QLT that, "We tend to 
give first shipments to areas which are being most successful. Right now, the German market is the hottest ST 
market for us- Since Switzerland is a German-speaking nation, they also received some, 11 

John Feagans, who is working on keyboard development for Atari, told OLT that he had been working with a 
blitter-equipped ST for more than a month. He also said that blitters for all STs will be available and that 
"there will be a place to put it." Some potential buyers had been concerned that a socket for the coprocessor 
would not be assembled into US versions of the ST. 

US release of the Atari Mega ST2 and Mega ST 4 is anticipated for September. 

— James Moran 


* * * * * 


Taken from Ziaag64 

xx surgFproteciion 


Copyright (C) 1987 by Garry Jones 

DO-IT-YOUSELF SURGE PROTECTION FOR YOUR COMPUTER 

When setting up a computer system, one piece of equipment which might get overlooked is a surge protector. 
The purpose of a surge protector is to protect equipment from voltage spikes and surges caused by lightning 
strikes on power lines (c'mon, it never rains is Southern California, does it?), electrical equipment turning on 
and off (you didn't really plug your computer into the same circuit as your refrigerator, did you?), the crummy 
wiring in your apartment that your landlords won't fix because they're too cheap, and just plain lousy 
erformance by your friendly local Edison Company. 

A surge protector works by clamping the voltage and preventing it from rising beyond 130 volts when a 
bidden increase occurs. To do this, a surge protector uses a device called a metal oxide varistor, or MOV for 
short. Of course, you want to know if they wear out, and when they do, how to tell. MOVs do have a finite 
life, depending on the number and severity of surges they're exposed to- When they fall, they typically create a 
short which will pop a circuit breaker if one is included in the circuit, immediately shutting off the power and 
saving the equipment* 

Buying a surge protector is something of a problem, since not all surge protectors are created equal* Good 
ones are fairly expensive (there's plenty of expensive junk out there, too); how do you tell the good from the 
bad, and what do you do for cash after you spent the last of it on some superwhizbang software for your new 
computer? Good news for you clever hacker types who can tell a hot soldering iron when you pick it up (by the 
wrong end): Make your own surge protector* It's easy, it's cheap, and best of all, it might even work. For 

the rest of you who haven't developed opposable thumbs yet, watch the ground for pennies, steal candy from 
babies and sell it to bigger babies, see a loan shark, and read PC [Can you say, "PC?" Sure. I knew you could* 
It does mean IBM, but your tongue didn't dry up and fall out of your mouth, did it?) Magazine's product tests 
and take their advice. 

Anyway, on to the project. You 1 11 need a power strip [make sure you get the kind you can disassemble with 
a screwdriver instead of a hacksaw) , three metal oxide varistors [General Electric part no. V130LA20A (which 
means 130 volts 20 amps) or Radio Shack catalog no. 276-568B) , some rosin core solder (DO NOT USE ACID CORE 
SOLDER OR FLUX: it will corrode the solder joints in time, ruining them) , some miscellaneous tools, like Xacto 
knives, alligator clips, wire cutters, etc., and a soldering iron* Three hands would be nice, but you can 
probably manage with two. Most of us do. 

Take the back off the power strip and look inside- It probably looks like the drawing Included in this 
archive. If it doesn't, don't worry. If It has outlets, wires (three of them?), and a cord, it'll work. Notice 
the three wires inside: they're probably black, green, and white. White is the hot wire, green the ground, and 
black the common. Now, strip some insulation off the wires as shown in the illustration. Take one varistor and 
solder one of its' wire legs to the white wire, and the other leg to the green wire as shown- Fasten an 

alligator clip to the leg being soldered between the solder joint and the varistor to prevent heat damage to the 

varistor while soldering. Do the same thing with the second varistor, except it should be soldered to the green 
wire and the black wire* Solder the third varistor to the black wire and the white wire. 

Clean the solder joints with a rag dipped in a little alcohol, and examine the joints. There should be a 
smooth shiny flow of solder between the wire leg of the varistor and the copper wire in the power strip. If the 
joint is dull, lumpy, or flawed in appearance, resolder it. When all the joints look good, reassemble the power 

strip. Sit back. Relax* You're done now* Wasn't that easy? Can you say, "Easy?" Sure. I knew you could. 


Garry Jones- 
^ompuserve; 72030,273 
GENIE: GXRAY 


* * * * * 
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Submitted by Stu Marcel lus 
HELP for using ARCX vl.2 

This is a short "How to..." on the use of ARCX version 1.2. This file is broken into two parts: 

1> loading ARCX. 

2> running ARCX* 

Since there are few differences in ARCX vl.l and ARCX vl.2, we will refer only to ARCX. It is strongly 
recommended that you download ARCX vl.2 as it is about 30% faster than vl.l and will therefore save you some 
time off line when recovering files. 

ARCX is the program that you will need to be able to recover and all of the files in the Atari RoundTable 

that are stored in the ARC format. See the file ARC.HLP for more info on the creation of an ARC f d file. 

LOADING ARCX 
************ 

To load ARCX, place a disk with your DOS file(s) on it in Dl: and turn on the computer. BE SURE TO HAVE 

ALL CARTRIDGES REMOVED AND ON XL/XE MACHINES, HOLD DOWN THE "OPTION" KEY TO TURN OFF BASIC. ARCX is known to 

work with Atari DOS 2.0 & 2.5, SpartaDOS <all versions>, and MYDOS 4.0 and up. ARCX ** WILL NOT ** work with 
SMARTDOS, 

Once to the DOS menu, you may set up your RAMdisk, copy files to the RAMdisk, etc.. It is recommended that 
you have a freshly formatted disk ready to receive the recovered files, so you might also want to format a disk 
now. 

Now place the disk with the file ARCX.COM on it in the drive and do a binary load of the file* From Atari 
DOS, this is option 'L' and the file name to load is ARCX.COM. 

From SpartaDOS, Just type ARCX <RETURN>. ARCX will load into the computer and be ready to run* 

Note that ARCX will work with all Atari 8 bit computers with at least 48K of RAM and one disk drive. 

RUNNING ARCX 

, ************ 

The first line of the ARCX menu will prompt you for a file name. If the file to be unARC'd has the 
extender of .ARC <a$ it should>, you need only type in the file name and not the extender. <le to recover 

TEST. ARC, you need only type TEST> If the file to be recovered is in any drive other than Dl;, you will need to 

give the device as part of the file name. <ie from a RAMdisk as D8, you would type D8:TEST> You may also see a 

directory of a disk by pressing the r + * key. NOTE: ARCX does not allow the use of wild cards, so you must enter 

the complete file name. 

Once you enter the file name to be recovered and hit <RETURN>, ARCX will ask for a destination drive. This 

is just a number from 1 to 8, There must be an active drive that is ready to receive the recovered filets). If 

you want to send the recovered filets) to D2:, put your formated disk in D2: , and press ’2', 

The last option that you will see is if you want the screen turned off or not while ARCX is working. 
Pressing the 'N' key leaves the screen on and pressing * Y 1 turns it off. Unless you are just curious, it is 

recommended that you turn the screen off <answer 'Y'> because ARCX is about 25-30% faster with the screen off 

than with it on. Once you press the 'Y 1 or ’N 1 key, ARCX will proceed to read the source file and write to the 
destination drive. 


POSSIBLE PROBLEMS 

***************** 

At the very start of the ARCX process, you may get several different 1/0 errors. I have found that most of 
these are because of the failure to give a valid file name. If this happens, make sure that you have given the 
COMPLETE file name with NO wildcards. As a matter of habit, 1 also enter the .ARC extender as part of the file 
name. Also make sure that the destination disk is freshly formated and is not write protected. 

If ARCX fails to do anything when you load it, MAKE SURE THAT BASIC IS OFF/ REMOVED* ARCX will lock up if 
BASIC is on. 

While ARCX is working, you may sometimes hear a high pitched beep. If the screen is on, you will also see 
the note "f ilename.ext Fails CRC Check 11 . This means that ARCX has encountered a file In the ARC'd file that for 
some reason does not match the original source file. This DOES NOT mean that the file is bad! This often 
happens on text files and is due to the block padding that most Xmodem file transfer systems do. If you get a 
CRC error, try to run the recovered programs* Odds are, they will run with no problems. If you do find that 
they will not run, use ARCX to recover the *.ARC file again and see if the error occurs again. If you have more 
problems, please leave E-Mail to one of the Atari RT SysOps with the file name/ number, and a full description of 
the problem. 

You may get a disk full error If you are using only one drive. ARCX supports the use of a RAMdisk and it 
is recommended that you use the RAMdisk if you can. If you have only one drive and no RAMdisk, you will be 
limited as to the size of the file that you can recover since both the source *.ARC file and the recovered 
file(s) must all fit on the same disk. As a rough guess, the *.ARC file should take up no more than 30% of the 
total disk space. 

Many people have left mail saying that ARCX has "Locked up" when in reality, it was doing just what it 
should be. This apparent lock up is because ARCX is fairly slow and does little disk access, so not much seems 
to be going on. As a rule of thumb, allow ARCX 1 minute for every 5K of *.ARC file size. <5K=40 SD sectors=20 
DD sectors> This way, you won't be expecting ARCX to just zip right through. 

Hopefully, this will answer many of your questions about how to use ARCX to recover the files. If you 
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should have a specific question, please feel free to drop E-Mail to one of the SysOps, and we’ll be glad to help 
in any way we can. 


Marty A. 

* * * * * 


PRIMER on FILE TRANSFER METHODS 
submitted by Stu Marcellus 


by Terry Smythe 
Sysop, Z-Node 40 

INTRODUCTION 

From time to time, many of us have had a need to transfer data from our own micro computer to another 
micro computer. The 2 computers might be close together, or they may be across town or across the nation. 
It's when they are not close together that problems occur because the telephone system becomes the link 
between the two computers, rather than a short piece of shielded wire. This ’Voice" telephone network is not 
"clean", and is a major source of aggravation and heartburn as it far too often adds extraneous 
characters commonly referred to as "line noise", to legitimate data as it moves through the wire. The 
net effect is a document, file, program, etc., that is often made virtually unusable by the involuntary 
insertion of these additional characters. 

The problem has its origin with the historical development, around the turn of the century, of our 
nationwide telephone network. Basically, solid copper connected telephones across town, across the 
nation, across the continent, and it had many mechanically actuated switches scattered along the way* These 
switches and many line connections eventually wear out, provoking a progressive deterioration of network 
efficiency. 

Many of these switches and much of the wire passes near other electrical equipment throwing off 
magnetic fields which adds to unreliability because of the principle of induced current* A magnetic field 
need only be brought near copper wire to "induce" a foreign current in it, in addition to legitimate data also 
passing through it at the same time. 

Until the late T 4Q's, early 5D T s, there was no real concern because the network carried only "voice" 
gnals. The combination of the human ear, coupled to an discerning brain, had the wonderful 
tural ability to filter intelligent conversation* What remained was simply thought of as "static", and 
uigely ignored. 


CURRENT SITUATION 

These "voice" telephone circuits are still a major highway over which a huge amount of computerized 
data now flows. Unfortunately, computers still lack the smarts Inherent within a typical human brain, 
and have great difficulty sorting out the good from the bad in what is passing through the wire. The 
ability to Ignore the junk along the way is still an elusive goal. True, networks have been made much more 
reliable In recent years, with the development and implementation of microwave networks, fibre optics, 
electronic switches, etc. Each in their own way contributing in some significant way to reducing the 
amount of "noise" passing through the network. 

Today, the network Is no longer solid copper wire. It Is more likely a mix of solid copper 
wire, microwave transmission, and fibre optics. However, even in a contemporary system there are 
still elements of the old copper network with its increasingly unreliable mechanical switches, 
deteriorating connections, etc* 

The bottom line is that network quality is really a function of the weakest link between 2 points. If 
your computer is connected into a computerized electronic switch you will enjoy relatively clean data 
transmission if you are connected to another computer which itself is connected into a computer switch, 
possibly the same one in the telephone company’s local switching centre. 

However, if one of the computers is still hooked Into an older mechanically switched centre, 
significant line noise is inevitable. Curiously, it can make itself known at one end, and not the other; 
where one user can be looking at an Incredibly scrambled screen display, while the other user is looking at a 
spotless screen display, wondering what's going on. 

The net result here is a high probability that when data is sent through the wire in an uncontrolled 
single trip fashion, it will pick up line noise somewhere along the way. In the case of conventional ASCII 
data {plain, readable text), the presence of a few extraneous characters is of no great consequence, 
relatively easy to detect, and fix with your favorite word processor or full screen editor. 

However, in the case of computer programs, the presence of a single extraneous character can make it 
totally unuseable* Detection is almost impossible, certainly for the neophyte, and patching the fix is not a 
trivial task. A considerable array of computer smarts is needed here, something that most users neither have 
nor want. 


ERROR DETECTION 

In the eyes (brain?) of the computer, characters introduced by line noise are every bit as legitimate 
as live data passing through simultaneously* It would take extraordinary programming talent to develop a 
communications system capable of sorting out the good from the bad as it streams by. The task is mind 
boggling, such that It simply is not done. 
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However, error detection methods have been developed, are in place now, and are quite effective 
and reliable. Fundamentally, they are all based upon the perception that if errors have been introduced 
EN ROUTE, then the file as received will be different from the file as transmitted. They do not really 
care what the specific error is, only that an error of some kind has been detected. 

Most of these error detection methods are based upon some simple arithmetic formulae applied to the 
same file at both ends, and the results compared. If the file as received has the same result as the file when 
sent, then it's reasonable to assume that the file has been transferred correctly. If different, then the 
file must be sent through again, and again, until it does come through the wire clean and correct. 

Doing such a calculation on an entire file is very inefficient. You really should not have to 
find out after an hour's transmission that errors have crept in. At this rate, it could take days to 
send a large file through the wire accurately. 

The simple fix is to break up the file into small blocks, typically 128 bytes long. This way, only 
those blocks where an error has been detected, need be re- transmitted again. So, a file of say 1500 blocks 
might take about an hour to transmit cleanly. Even on a noisy line, a maximum number of bad blocks likely 
would not exceed 30-50. In this way, that portion of the file needing to be re- transmit ted is reduced to a 
manageable level - 


ERROR DETECTION METHODS 


In August 1977, Ward Christensen, a pioneer in data communications, developed a method of file 
transmission with simultaneous error detection. He simply called it MODEM 2 (Release 2,0), but very 
quickly it became affectionately known as the "Christensen" protocol. 

In its simplest form, this original, somewhat primitive error detection scheme added up the values of 
all characters In the 128 byte data stream, and sent this value through the wire. The receiver meanwhile was 
adding up the values of the characters as they arrived, and compared the result with the "CHECKSUM" value sent 
through by the sender. 

If these 2 numbers did not agree, the receiver sent through a code telling the sender to repeat the 
transmission of that bad block. This process was repeated, if necessary, up to 10 times for a particular 
bad block. Only when the 2 numbers were identical, did the receiver send through a code acknowledging 
correct block received. The sender would then move on to the next block of 128 characters, repeating the 
process all over again. 

This early method of error detection was deliberately made super-simple, so that it could apply to a 
whole host of different machines, under an almost infinite array of data transmission conditions. 
However, because of its simplicity, it did let a few technically obscure errors sneak through. 
Consequently, Ward Christensen and Chuck Forsberg collaborated in the development, and release in 1982, of 
the CRC (Cylic Redundancy Checking) error detection scheme which has remained in widespread use to this day. 

Because it guarantees a minimum level of error detection confidence of not less than 99.9969%, CRC is 
accepted as a reliable method of ensuring clean and accurate file transfer. Most systems of file 
transfer now employ CRC, or a derivative of it, as their principal method of error detection. Please 
note this is error detection, not error correction, a function still best left to human 
intelligence. 

Uncertain how or when, but this protocol became universally Known as XMODEM. The original Checksum 
method was never abandoned, and to distinguish between them, they are universally known as: 


XMODEM - Checksum protocol 


XMODEM CRC - CRC protocol 

Where the Checksum method simply added up the values of the characters in a 128 character block, the 
CRC method does sequential division on each character in the block, resulting in a significant 
improvement in error detection* 

When there are no more characters for sequential division, the final remainder is the CRC value 
sent through by the sender. The receiver applies the same calculation to the incoming characters, and 
compares the results with the Incoming CRC value. If equal, the block is acknowledged and the next block is 
allowed to come through. Inequality would require re- transmission of the block, to a maximum of 10 
times. 

If still unequal after 10 tries, the transmission will be automatically terminated. 

ENHANCED FILE TRANSFER METHODS 

With normal equipment upgrades, such as microwave and fibre optics, telephone companies around the 
world have progressively improved their abilities to transfer data more reliably over voice grade lines. As 
line quality improves, line "noise" decreases, and data files may be successfully transferred with fewer 
"hits". In fact, it is commonplace today to experience file transfers with no "hits" at all. This improvement in 
data transmission capability provoked a realization that the 128 character block size had become 
inefficient because of its associated overhead. Furthermore, new methods of data transmission, 
such as DATAPAC, resulted in dramatically inefficient use of the telephone network, (e.g. a DATAPAC 
"packet 11 capable of carrying 1024 characters was carrying only 128 characters!) 

To overcome this inefficiency. Chuck Forsberg developed the YM0DEM protocol, where the block size was 
increased to 1024 characters. In it, he inserted a rather nifty feature where the protocol would automatically 
step down to 128 character block size if line noise got so bad as to degrade elapsedfile transmission 
time. This auto step-down has been universally adopted at 3 consecutive "hits" (bad blocks). 

The YMODEM protocol has only a modest improvement in elapsed file transmission time over the conventional 
voice network. However, it provided a dramatic improvement on the DATAPAC network by simply using the packet 
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size more efficiently. 

Not satisfied with this improvement. Chuck Forsberg continued with his development activities and 
hme up with YMGDJEM BATCH. This allowed rapid transmission of a group of files sequentially, to reduce the 
verhead associated with Keyboard entries to set up the communications programs at both ends with the 
transfer of each file. 

While YMODEM is referred to as a protocol, it really is a "method 11 of file transfer. The CBC protocol 

is still in use at its heart, no matter if in 128 or 1024 character block size. 

Ever vigilant to technological developments. Chuck continued to perceive opportunities for further 
Improvements and has recently developed and released to public domain a new file transfer protocol which 
he calls ZMODEM, It is a new, sophisticated protocol aimed at efficient file transfer with time sharing 

systems, satellite relays, and wide area packet switching networks, 

ZMODEM will work only if both ends support this new protocol, but it has built into it a 
fall-back routine whereby it will automatically fail-back to YMODEM protocol, if ZMODEM is not supported at 
the other end. It uses a "streaming 11 technique whereby data is flowing continuously, with simultaneous 
error detection in a moving window of up to 256 characters, depending on line quality, using the 
capabilities of the full duplex network. 

This is an oversimplified description of ZMODEM. It is quite sophisticated, complex to learn and 
use, and not yet in widespread use. No attempt will be made here to describe this in anything other than 
this crude overview. Those interested otherwise are encouraged to read Chuck Forsberg 1 s paper on his ZMODEM 
protocol (ZMODEM, DOC) , 

There are other protocols, some somewhat obscure, some very complex, and some proprietory. For example, 
MNP, BLAST, BISYNC, SDLC, HDLC, X.25, X.PC, etc., which are not in widespread use, tend to be tightly 
bound to the fortunes of their suppliers, and which the average users will not likely encounter. Suffice to 
note their presence so those interested may do additional research. 

BAUD RATES 

While not normally a function of file transfer methods, it does seem appropriate to briefly consider the 
speed at which data flows through the telephone wire. BAUD is simply an international unit of measurement 
that has become synonymous with BPS (Bits Per Second) . The latter has come into popular useage, and 
tends to be a much more meaningful term. 

Most users will encounter modem/computer/communications system configurations using baud rates of 300 
BPS, 1200 BPS, and 2400 BPS, Lower or higher baud rates are still extremely rare. By a huge margin, 
the most popular is 1200 Bits Per Second, and is the one most frequently recommended, and at modest cost. 

300 baud configurations should be avoided for they deliver data through the wire at painfully slow speeds, 

T n fact, 300 baud becomes cost prohibitive if employed over long distances. 

By way of comparison of how long it may take to transfer a file over the wire at various baud rates, 

nsider the following example of a typical file taking 24 minutes to pass through the wire at 300 baud: 

File transferred at 300 baud - 24 minutes 

Same file at 1200 baud - 6 minutes 

Same file at 2400 baud - 3 minutes 

Modems capable of transferring files at baud rates higher than 2400 are available, but they are 
complex, expensive, and typically require the identical modem at both ends, because of the absence to 
date of consistent universal standards of methods of file transfer at 4800 and 9600 baud. These standards 
will ultimately emerge, but for the present, most users will likely choose to stay with proven techniques at 
baud rates of 2400 or 1200, 


COMMUNICATIONS TOOLS 

There is no shortage of software out there to achieve reliable data communications, using these 
protocols. It ranges from costly dedicated utilities, such as for AES equipment, to low cost generic 

systems placed into the world of "Shareware" software. A few of the more prominent of these Shareware 
products are: 

PROCOMM v* 2,42 - Excellent, supports all protocols but ZMODEM 
QM0DEM v 2,4 ~ Very good, supports most protocols, 

2C0MM v 2.0 * Excellent, but complex. Supports all protocols discussed here. 

These are good, and they are cheap. As with most Shareware software products, prices in the $40 - $60 
(U.S.) range are commonplace. There are others, too many to discuss here. See them out, do your homework, 
choose that which suits you best. 


SUMMARY 

Most users will be presented with the following optional methods of transfering files from one 
ro-computer to another; 


1. ASCII 
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Straight one way trip of data without any form of error detection in place. Highly vulnerable to data 
CORRECTION by normal line noise adding extraneous characters to the file. 

2. XMODEM 

Very early method of file transfer, using primitive Checksum protocol, at a fixed 128 character 
block size. Risk of a few obscure errors slipping through. 

3* XMODEM CRC 

Reliable method of file transfer using the CRC protocol at a fixed 128 character block size. Not very 
efficient, but highly compatible with most communications systems. 

4. YMODEM 

Reliable method of file transfer using the CRC protocol at both 128 and 1024 character size blocks. 
Reasonably efficient, and reasonably compatible with many communications systems. 

5. YMODEM BATCH 

Reliable method of file transfer using the CRC protocol at both 128 and 1024 character size blocks, with 
an added option of sending a number of files in Batch mode. Quite efficient, and marginally compatible 
with a few communications systems. 


6. 2MQDEM 

Sophisticated, reliable, and efficient method of file transfer, using a modified CRC protocol of up 
to 256 character block size with auto step-down in accordance with line quality. Marginally compatibility 
with very few communications systems. Currently rarely found. 

TYPICAL APPLICATIONS 

1. Generic public domain software may be reliably transferred between 2 computers having 

incompatible disk formats* If the 2 computers are together in the same room, they may simply be connected 
together through their serial ports, then 2 compatible communications systems may then facilitate file 
transfer between the 2 at very high speeds (baud rates) . Over distance, the same can be achieved with modems 
at both ends, and l1 talking ,, over the voice telephone network at much lower baud rates. The CRC protocol 
virtually guarantees accurate transfer. 

2. Text files, saved in ASCII form, may be transferred over the telephone wires to most any 

location. Typical application might be the content of a magazine article, or a book, where the author 
finalizes content as to language and spelling, etc., and transmits it to a printer. While 
faithfully preserving content, the printer sets it up as to publication format, type style, etc., and can 
go directly to press. A "proof” copy is not sent back to the author for proofreading. The CRC protocol 
virtually guarantees error free transfer, where ASCII would be a disaster. 

3. Business data, such as accounting, inventory, sales, etc., may be reliably transferred, 
using the CRC protocol from a remote site, to a central computer for consolidated processing. Also 
possible to set up this kind of file transfer as an automatic interrogation during the middle of the 
night when rates are lowest. 

CONCLUSIONS 

There was a time (not so long ago) where it was considered quite NAPPROPRIATE to use a computer to send 
files through the voice telephone network. Between an absence of standards on file transfer 
protocols and line noise, received files were rendered almost totally useless. 

However, this Is no longer true. Reliable file transfer protocols are now in place, and files may now 
be transferred between micro -computers with a high degree of reliability. 

While this may mean reduced revenues for some industries, in particular the publishing industry where 
transcriptions (and related revenues) can now be a thing of the past, business and industry can 
look forward to substantial improvements in staff productivity and significant reductions in 
publishing costs, by the application of the '"type-it-once” principle. 

In these tight money times, now is the time for business and industry to be creative in their use of 
micro-computers and data communications capability. 

Were it not for the vision and foresight of Ward Christensen and Chuck Forsberg, and others like them, 
these wonderful tools would be denied to us, and companion benefits unattainable. What they have 
done is indeed very much appreciated today* They are to be commended for their achievements. 

Terry Smythe 

Sysop , 2-Node 40 

55 Rowan d Ave 

Winnipeg, Manitoba 

Canada R3J 2N6 

(204) 832-3982 (Voice-res) 

(204) 832-4593 (Z-Node) 

(204) 945-6713 
15 Apr 87 


* * * * * 
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M.A.C.C. RENEWAL FORM 

Record Number : (by Executive) 

First Name : Inti : 

Last Name 
Address 
Area of City 
City 

Postal Code 
Area Code 
Phone Number 


Province : 


Unlisted (Y) (N) 


Modem 

Type 


BBS 


k k k k k 

: (Y) (N) Baud : 


* * * * * 

INTERESTS 


Newsletter 


Topics 


Comments 


k k k k k 

Membership / / to / / 


NEXT MEETING 

Gct*l 1987 

Grant Park Harrow Recreation Assoc. 
/ 550 Harrow Street 

c 7:30 P*M* 

* * * * * 


Manitoba Atari Computer Club 

MACC is an independent, and non-profit user's group with no 
connection to the Atari Company* We are a group interested in giving the 
latest news, reviews, rumors, and public domain software to our members* 
Material in this newsletter may be copied, as long as credit is given to 
the newsletter as well as the author. 

***** 

MAILING ADDRESS 


M.A.C.C. 

C/O Rick Singbeil 
483 Ferry Road 
Winnipeg, Manitoba 
R3J 1W5 
Canada 

***** 
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